Technical Field
This disclosure relates generally to management of computing resources in a federated environment.
Background of the Related Art
Federated environments are known in the art. A federation is a set of distinct entities, such as enterprises, organizations, institutions, or the like, that cooperate to provide a single-sign-on, ease-of-use experience to a user. A federated environment differs from a typical single-sign-on environment in that two enterprises need not have a direct, pre-established, relationship defining how and what information to transfer about a user. Within a federated environment, entities provide services that deal with authenticating users, accepting authentication assertions (e.g., authentication tokens) that are presented by other entities, and providing some form of translation of the identity of the vouched-for user into one that is understood within the local entity. Federation eases the administrative burden on service providers. A service provider (SP) can rely on its trust relationships with respect to the federation as a whole; the service provider does not need to manage authentication information, such as user password information, because it can rely on authentication accomplished by a user's authentication home domain, which is the domain at which the user authenticates.
In particular, a federated entity may act as a user's home domain that provides identity information and attribute information about federated users. An entity within a federated computing environment that provides identity information, identity or authentication assertions, or identity services, is termed an identity provider (IdP). Other entities or federation partners within the same federation may rely on an identity provider for primary management of a user's authentication credentials, e.g., accepting a single-sign-on token that is provided by the user's identity provider. An identity provider is a specific type of service that provides identity information as a service to other entities within a federated computing environment.
In this type of operating scenario (when the SP application itself does not handle the user authentication), there is a need to secure the application's configuration, namely, the identity of which IdP(s) are allowed to authenticate users on the SP's behalf. Ideally, this configuration should only be available to administrators who are authorized to manage the configuration (including any stored artifacts that may be used to identify the IdP system). If a configuration is not highly-secured, a rogue administrator might wreak havoc, e.g., by altering artifacts for an IdP, or by installing artifacts for a bogus IdP. Also, after an IdP has been discontinued from use, a rogue administrator could cause significant security concerns by resurrecting the configuration for the unapproved IdP.
It is also known to use a login service where SAML (Security Assertion Markup Language) security has been deployed. The SAML security model offloads user authentication to an IdP, which handles the user login. After the IdP has verified the user's identity, the IdP issues to a service provider (SP) application an identity assertion representing the authenticated user. On receipt of the identity assertion, the SP cryptographically verifies the user's assertion, and the SP may allow the user access to resources if the assertion verification is successful. As a prerequisite to verifying assertions, typically the SP is partnered with the IdP and obtains information about the IdP, including the IdP's certificate used with cryptographic operations. In many systems, a service's certificate typically is “public” information that can be widely accessed and, as such, the information may be stored in a directory with wide access permissions. While the IdP's certificate itself is indeed public, it is a disadvantage if there is no clear method for an SP to securely-configure trusted use of the IdP's certificate for validating user identity assertions. Furthermore, an SP may provide service to a variety of websites hosted by the service, and an administrator might require one website to use authentication by a particular IdP while another website requires authentication from an alternate IdP. In the past, there has been no clear method to secure this configuration.